crash_handler: truncate a panic message that does not fit the trace string instead of dropping it - #38950

Problem

• A CrashReason::Panic whose message compresses to more than the room left in the trace string (about 680 bytes on a typical Linux trace, less with more or longer frames) produces a trace string that ends right after the 0 reason tag: the frames are there, the message is gone, and nothing reports it. That string is what gets printed and what report() uploads. The pinned bun.report decoder (bun-tracestrings, parsePanicMessage) throws on the empty payload, so its parse() returns null and bun.report rejects the whole report, frames included.
• Cause: encode_trace_string (src/crash_handler/lib.rs) compressed the message into a 2048-byte buffer, base64-encoded that into another 2048-byte buffer, and appended the result with a single write_all to the 1024-byte trace_str_buf its callers render into. BoundedArray::append_slice is all-or-nothing, so once header + frames + base64 exceeded 1024 bytes the append failed as a unit, and TraceString's Display impl discarded the error (let _ = encode_trace_string(..)). The two 2048-byte intermediates only hid the real limit.
• Observed with a debug build and a message argument on the crash_handler.panic() test hook: a 2048-character incompressible ASCII message and a 1024-character CJK message both produced a 117-byte trace string with an empty payload; 900, 1000 and 1024 characters of base64-alphabet text (all within the 1024-byte cap the Rust panic hook applies) did not fit either. An 11-character message produced a 143-byte trace string that decoded normally.

Fix

• encode_trace_string writes into the TraceStringBuf (BoundedArray<u8, TRACE_STRING_MAX_LEN>) itself instead of an arbitrary writer, so when it reaches the message it knows how much room is left. write_panic_message turns that room (minus the /view suffix when one follows) into a maximum compressed size and compresses the longest prefix of the message whose zlib stream fits: the whole message is tried first, and only if that fails does it bisect the cut. The cut is backed up to a UTF-8 character boundary (utf8_prefix); a message that fits is passed through byte for byte.
• Why this is correct: the prefix's stream is a complete zlib stream, so bun.report inflates it with the decoder it already has (a stream cut short would not inflate at all, since its final block and Adler-32 trailer would be missing), and the wire format does not change. A message that fits encodes exactly as before; the two "encoded whole" test cases pass on the unfixed encoder as well.
• Why fit-to-room rather than a bigger buffer plus a message cap: the part of the trace string before the message has no fixed size. The base URL is BUN_CRASH_REPORT_URL verbatim; each of the up to 20 frames that falls outside bun's own image carries that module's file name on Windows (StackLine::from_address), so a crash with its frames inside a native addon with a 30-character file name can put several hundred bytes of names ahead of the message; crash_handler: put the executable's debug id in the trace string #38838 adds more header fields. With a few hundred bytes of header even an ordinary 1 KB unwrap() message no longer fits today, and any fixed split between buffer size and message cap can be pushed past the same way by a longer base URL or longer module names, which is how the 2048-byte intermediates came to be wrong. Computing the budget from the bytes actually left is the only shape under which the encoder cannot emit an undecodable string; it also makes TRACE_STRING_MAX_LEN a plain knob (raising it to keep more of long messages is a one-line change that is safe either way), and it covers panic_impl and Bun__crashHandler, whose messages are not capped anywhere.
• Cost: the overflow path makes at most about log2(len) + 2 compress2 calls, each the same one-shot call (and the same internal deflateInit allocation) the current code makes once; zlib stops as soon as the output buffer (at most 768 bytes) is full, so no attempt scales with the message. Scratch space is 768 + 1024 bytes plus a 1024-byte local in the Display impl, down from 2048 + 2048.
• TraceString's Display impl encodes into a local TraceStringBuf and forwards it, so the five existing TraceString sites (two panic paths, three ZigError stderr paths) are unchanged, and an encoding error still leaves whatever was encoded to be printed, as before. TraceStringAction loses its PartialEq derive, which the removed == was the only user of.
• Both trace_str_buf declarations become TraceStringBuf so they cannot drift from the encoder's limit. The one in rust_panic_hook is deleted by crash_handler: report Rust panics through crash_handler() and test the panic hook #38927, which routes Rust panics through crash_handler(), so merging the two PRs needs that one line resolved. crash_handler: report Rust panics through crash_handler() and test the panic hook #38927 also caps the hook's message at 1024 bytes; as measured above that alone does not avoid this bug, and with this change any length yields a decodable report.
• crash_handler.panic() in bun:internal-for-testing takes an optional message (src/runtime/api/crash_handler_jsc.rs). Without one it panics with the same message as before, so the existing assertions on it are unaffected.
• Verified:
  • test/cli/run/run-crash-handler.test.ts, trace string panic message: decodes the trace string by walking the format (header, feature VLQs, frames, 0 tag) and inflating the payload with a fatal UTF-8 decoder. A short and an empty message decode whole. Two messages built from TRACE_STRING_MAX_LEN bytes of hash output (as hex, and as one 3-byte CJK character per byte) decode to a non-empty strict prefix of the message, with the trace string within 64 bytes of the limit, so the cut is the longest one that fits rather than an arbitrary shorter one; the CJK case also proves the cut lands on a character boundary. Since the payload can hold at most 3/4 of TRACE_STRING_MAX_LEN compressed bytes and that much entropy cannot compress below it, these messages cannot fit on any platform or header size, and a future change to the constant keeps them unfittable.
  • With the test hook but without the encoder change, the two long-message cases fail with panic reason has no payload: the message was dropped; with the released bun all four fail because the hook ignores its argument; with bun bd test all four pass (the hex message is cut to 1213 characters, the CJK one to 413, both trace strings exactly 1024 bytes). The whole file passes (21 pass, 9 platform skips), as does test/cli/run/crash-report-command-char.test.ts; the Windows x64 and arm64 CI lanes ran the new cases as well.
  • cargo check -p bun_crash_handler for x86_64-pc-windows-msvc, aarch64-pc-windows-msvc, aarch64-apple-darwin and x86_64-unknown-linux-gnu (uLong is 32-bit on Windows; compress_message treats a length that does not fit it as a prefix that does not fit), and cargo clippy on the crate is clean.

Background

• Trace string: the https://bun.report/<version>/<payload> URL the crash handler prints and optionally uploads. The payload is positional: platform and command characters, a format version character, 7 characters of git sha, then VLQ-encoded fields (feature bits, one entry per stack frame, a 0 terminator), then a reason character and its payload. A frame outside bun's own image is encoded as the module name plus an offset, which is the variable-size part of the header. For a panic the reason is 0 and the payload is the zlib stream of the message in base64 with the padding stripped; bun.report's decoder inflates everything after the tag. The string is assembled in a stack buffer in the crash handler, which is where the 1024-byte limit comes from.
• VLQ: the base64 variable-length integer encoding that source maps use; every numeric field in the payload is one.
• BoundedArray<u8, N>: a fixed-capacity array plus a length, used so the crash path does not allocate. Its write_all appends the whole slice or nothing.
• Unpadded base64 takes ceil(4n / 3) bytes for n input bytes, which is where budget * 3 / 4, the largest n whose encoding fits in budget bytes, comes from.
• compress2 is zlib's one-shot compressor. When the output buffer is too small it returns Z_BUF_ERROR as soon as the buffer is full instead of compressing the rest of the input, which is what keeps the retries cheap.